Rule processing method, apparatus, and computer-readable medium to generate valid combinations for selection

ABSTRACT

A computer-implemented method of providing a list of product choices from products whose compatibility is characterized by a ZDD rule model having one or more Include or Exclude rules, where the list of product choices is provided in response to user-selected attributes and/or enumerations. The method comprises selecting attributes and enumerations thereof from a list of attributes and enumerations of the products, creating a ZDD sub-tree by scanning an Include ZDD rule and keeping paths having user-selected enumerations set, determining paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, checking the potentially valid combinations against any Exclude ZDD rules to determine valid combinations and excluding combinations that are excluded under the Exclude ZDD rules, and providing the valid combinations to a user as an indication of valid product choice. Scanning may include examining nodes of an Include ZDD rule against an Index value of selected enumerations to create a node in the ZDD sub-tree, or examining nodes of the ZDD sub-tree against an Index value of selected enumerations to recursively create a node in the ZDD sub-tree. Potentially valid combinations of the determining step comprise nodes of paths terminating at a “one” node of the ZDD sub-tree. Other aspects include a corresponding apparatus that implements the method and a computer-readable medium including program instructions to effect operation of the method in a computer.

CROSS-REFERENCE TO RELATED PATENTS AND PATENT APPLICATIONS

This invention claims the benefit of Provisional Application Ser. No. 60/506,156 filed on Sep. 29, 2003 in the names of Huelsman, et al., entitled Improved Method and Apparatus for Rule Processing, which is incorporated herein.

This invention is also related to U.S. patent application Ser. Nos. 10/101,151 and 10/101,154, each filed on Mar. 20, 2002 in the names of the same inventors hereof, which are incorporated herein.

BACKGROUND

This invention concerns an improvement to a method or apparatus for rule processing preferably utilizing zero-suppressed binary decision diagrams (ZDDs) to express and manipulate a business rule, but more specifically, to a method or an apparatus to generate valid combinations of features or components of a product or service for selection by a user based on an arbitrary set of input specifications.

Specialized rule processing or artificial intelligence (AI) applications are often employed to produce valid combinations of compatible product components, features, or operational characteristics. These applications typically display a table of alternatives product selections on a computer monitor given an arbitrary set of search criteria supplied by an end user, such as a customer engaged in on-line shopping. It becomes a challenge to generate compatible product or service configurations when subparts or components of the product or service become numerous thereby exponentially multiplying the number of possible valid or invalid combinations.

For customer service applications, it is also desirable to provide search results instantaneously, e.g., within a couple of seconds or less. For many complex products, such a constraint is difficult to meet with prior systems.

A rule processing system described in the above-mentioned, incorporated U.S. patent application Ser. Nos. 10/101,151 and 10/101,154 utilizes a form a binary decision diagrams (or directed acylic graphs) to provide a user with conflict and selection advice based on a given set of input parameters, therein called attributes and enumerations thereof. To extend the utility of that invention, the present invention also utilizes a form of binary decision diagrams (or directed acylic graph), preferably zero-suppressed binary decision diagrams, to provide an end user or customer with a number of valid choices of product or service configurations based on a given arbitrary set of input parameters, e.g., product specifications. FIG. 1 shows an example of graphic shown on a user interface when a customer seeks to purchase a computer monitor. In the example, the customer may specify attributes, such as a manufacturer, viewable size, interface type, resolution, contrast ratio, or system type. Based on these search criteria, the rule processing system may display all available computer monitors meeting the criteria along with a listing of enumerations, such as product features, characteristics, price, rebates, or other data about each selected product attribute.

The present invention takes advantage of the rule processing procedures of the prior related inventions to provide a user with valid selections of a product or service based on a set of specified inputs or search criteria.

SUMMARY

According to an aspect of the present invention, a computer-implemented method of providing a list of product choices from a universe of product specifications whose compatibility is characterized by a ZDD rule model having one or more Include or Exclude rules, where the list of product choices is provided in response to user-selected attributes and/or enumerations. An exemplary method comprises selecting attributes and enumerations from a list of attributes and enumerations associated with the products, creating a ZDD sub-tree by scanning the Include ZDD of the rule model and keeping paths having user-selected enumerations set, determining paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, checking the potentially valid combinations against the Exclude ZDD of the rule model to determine valid combinations, excluding combinations that are excluded under the Exclude ZDD, and providing the valid combinations to a user as an indication of products having valid or compliant specifications. Typically, the providing step includes displaying valid product choices on a display monitor. In a specific embodiment, the scanning includes examining nodes of the Include ZDD against an Index value of selected enumerations to create a node in the ZDD sub-tree. Alternatively, the scanning may include examining nodes of the ZDD sub-tree against an Index value of selected enumerations to recursively create a node in the ZDD sub-tree. Potentially valid combinations of the determining step comprise nodes of paths terminating at a “one” node of the ZDD sub-tree. Another aspect of the invention comprises a corresponding apparatus that implements the aforementioned method or a computer-readable medium including program instructions to effect operation of the method in a computer.

According to another aspect of the present invention, an apparatus to provide a user with a list of product choices from products whose compatibility is characterized by a ZDD rule model having one or more Include and Exclude rules comprises an input device to enable selection of attributes and enumerations from a list of attributes and enumerations associated with the products; a processor including routines to effect creation of a ZDD sub-tree by recursively scanning the Include ZDD of the rule model and keeping paths having user-selected enumerations, to determine paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, and to check potentially valid combinations against an Exclude ZDD of the rule model to find valid combinations, and an output device that outputs the valid combinations as an indication of products having valid specifications.

In addition, another aspect of the present invention includes a computer-readable medium to effect operation of a computer to provide a list of product choices from products whose compatibility is characterized by a ZDD rule model having one or more Include or Exclude rules where the list of product choices is provided in response to user-selected attributes and/or enumerations. The computer-readable medium includes program instructions to effect selection of attributes and enumerations thereof from a list of attributes and enumerations associated with the products, creation of a ZDD sub-tree by recursively scanning an Include ZDD of the rule model and keeping paths having user-selected enumerations set, determination of paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, checking potentially valid combinations against an Exclude ZDD of the rule model to determine valid combinations and excluding said combinations that are excluded under the Exclude ZDD, and provision to a user a choice of products (or services) having valid combinations of specified features.

Other aspects and features of the invention will become apparent upon review of the following description. The invention, though, is pointed out with particularity by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is GUI display illustrating user-selections of attributes and enumerations, e.g., product specifications, and a resulting list of product choices responsive to the user-selected attributes and enumerations.

FIG. 2 is a flow diagram of an illustrative procedure according to an aspect of the present invention.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENT

The present invention makes use of zero-suppressed binary decision diagrams (ZDDs), which are referenced above in the Cross-References To Related Patents and Patent Applications. A ZDD is made up of an Index that maps directly to enumerations (e.g., product features), a “Then” leg that points to a ZDD node, and an “Else” leg that points to another ZDD node. To obtain a list of choices according to the herein described illustrative embodiment as shown in FIG. 2, a user typically uses a keyboard and pointing device of a computer to provide a given a set of selections on various input product attributes and enumerations. In response, the method and apparatus of the present invention acts on the user-selected inputs to output another set of output attributes with valid combinations of input selections. The output is preferably displayed on a computer monitor, or supplied to an I/O device for printing or other output.

Include Processing:

To generate valid choices or combinations, the method or computer implementation thereof scans through an Include ZDD of a packaged ZDD rule model and keeps all paths in the Include ZDD that have enumerations set (e.g., asserted or selected). For every node traversed during the scan, one of the following steps occurs with respect to a node in the include ZDD:

-   -   If the index encountered matches one of the input enumerations         selected by a user, a node is created in a new ZDD tree that         includes this index and the subgraphs pointed to by the Then and         Else legs of the node.     -   If the index is in the set of output enumerations, a new node is         created, as above.     -   If a Constant node is encountered, the constant is returned.     -   Otherwise, the subgraphs pointed to on the Else leg of the node         is returned.

The above rules describe a recursive procedure to create the ZDD. The resulting ZDD is a sub-tree of the original Include ZDD of the rule model characterizing the product or service in question, and is used to produce valid combinations or choices based on user-selected input criteria. The preferred method or apparatus then adds in nodes for all of the enumerations that are always valid. This modified ZDD is then stored as a SelectionCombos object described in the appendix, which is returned to the user or calling routine.

Traversing the SelectionCombos Tree Object:

Valid combinations are read from the SelectionCombos object using a GetFirstCombo routine, also described in the appendix, to move to the first valid combination. A first combination by finding a complete path through the ZDD that ends on the “one” node. Then the GetNextCombo routine is invoked to get the next valid combination. GetNextCombo walks the next path in the ZDD. It's important to note that the order of the combinations is the same as the index order from the Include ZDD.

Exclude Processing:

As each possible combination or choice is produced, it is checked against the Exclude ZDD of a packaged rule model characterizing the product or service. If the resulting combination is excluded, then another combination is produced. When a combination is found that isn't excluded, it is returned to the calling routine or end user by way of a display or other output as a valid choice or combination. Thus, combinations are excluded in real-time. Because combinations are excluded in real-time, one cannot obtain an accurate count of valid combinations until completion. One can, however, obtain an upper limit of the number of valid combinations by counting all paths in the resulting include ZDD.

Bookmarks:

As the SelectionCombos object is traversed, locations can be bookmarked. This allows the user to jump back to the bookmark and start getting combinations from that location. A MakeBookmark routine writes a new bookmark in memory for later recall. It creates a collection of the enumeration indexes on a current path and adds this collection to the end of an array in the SelectionCombos object. The routine returns the index of the new array entry. A GotoBookmark requires an integer. This routine will move to an existing bookmark in the array of bookmarks.

Preferable, the bookmarks are not ordered or sorted. They stay in the order that they are created. For example, if the following sequence of operations is performed:

-   -   GetFirstCombo,     -   GetNextCombo, GetNextCombo, GetNextCombo,     -   MakeBookMark,     -   GetNextCombo, GetNextCombo, GetNextCombo, GetNextCombo,     -   MakeBookMark, GotoBookMark(0),     -   GetNextCombo, GetNextCombo,     -   MakeBookMark

The bookmarks will appear, as follows: Bookmark Index 0 1 2 Combination # 2 6 4

The bookmarks preferably remain for the entire life of the SelectionCombos object.

Based on the above teachings, the invention also embraces modifications not explicitly shown in the drawings or written description. In particular, the invention is preferably practiced utilizing zero-suppressed binary decision diagrams (ZDDs) but software emulations or other representations of ZDDs may be employed to achieve substantially the same results. Typically, a keyboard and pointing device (e.g., a mouse) is used to supply inputs to a GUI (graphical user interface). The GUI also is used to provide results to the user. A processor (desktop, handheld, or other portable computing device) typically implements the method. Access and transfer of data may occur locally or via a network, e.g. the Internet or a LAN. Also, the illustration was directed to a product configuration business rule, but may be extended to other scenarios to the same extent described in the incorporated and related patents and patent applications. Accordingly, the disclosure is not intended to limit the scope of the invention set forth by the appended claims.

Appendix

Notations Used

The notation used for attributes in this document is “Attr” followed by a number. The first attribute in the examples is Attr1.

The notation for enumerations is “Enum” followed by two numbers. The first number is the attribute that it belongs to. The second number is its number within the attribute from 1 to 5.

The ellipses symbol “ . . . ” is used to show a range of enumerations.

For convenience and illustration, every attribute in the examples shown herein has five (5) enumerations.

The word “related” means that the attributes are in the same rule. The double arrow symbol “

” also means that the attributes are related.

GetCombosForSelections Algorithm

Description: Given a set of selections (enumerations and attributes), returns all combinations of a second set of attributes.

Exemplary Code

This routine is only accessible through an API interface. The entry points are:

-   -   CombosForSelections to create the object     -   GetNextCombo to display the next combo

GetComboCount to determine the total number of combos. /**************************************************************************************** \   Proc: CombosForSelections(zdd, selections, inputGroups, outputGroups) \**************************************************************************************** / SelectionCombos *CombosForSelections(HBdd hBddI, HBdd hBddX, IntArray &aSelections,    IntArray &aInputGroups, IntArray &aOutputGroups, IntArray &aCombo) {   int nGroups;   BddErrorCode retVal = ecSuccess;   Dm_Manager *ddI, *ddX;   Dm_Node *pZddI, *pZddX;   GroupItem *pGroupInfo;   HManager hManagerI = g_BddTableArray[hBddI].hManager;   SelectionCombos *sc = NULL;   if (ecSuccess == (retVal = GetBddFromHandle(hBddI, &pZddI, &ddI)))   {    if (ecSuccess == (retVal = GetBddFromHandle(hBddX, &pZddX, &ddX)))    {     pGroupInfo = g_ManagerTableArray[hManagerI].groups;     nGroups = g_ManagerTableArray[hManagerI].nGroups;     sc = CombosForSelectionsC(ddI, ddX, pZddI, pZddX, aSelections,      aInputGroups, aOutputGroups, aCombo, nGroups, pGroupInfo);    }   }   return sc; } SelectionCombos *CombosForSelectionsC(Dm_Manager *ddI, Dm_Manager *ddX,    Dm_Node *pZddI, Dm_Node *pZddX, IntArray &aSelections,    IntArray &aInputGroups, IntArray &aOutputGroups,    IntArray &aCombo, int nGroups, GroupItem *pGroupInfo) {   SelectionCombos *sc = new SelectionCombos( );   sc->setGroupInfo(nGroups, pGroupInfo);   sc->setIncludePac(ddI, pZddI);   sc->setExcludePac(ddX, pZddX);   sc->setInputs(aSelections, aInputGroups, aOutputGroups);   sc->generateCombos( );   sc->getFirstCombo(aCombo);   sc->getNextCombo(aCombo);   return sc; } /**************************************************************************************** \   Proc: GetNextCombo(tree, currentCombo) \**************************************************************************************** / void GetNextCombo(SelectionCombos &sc, IntArray &aCombo) {   sc.getNextCombo(aCombo); } /**************************************************************************************** \   Proc: GetComboCount(tree) \**************************************************************************************** / int GetComboCount(SelectionCombos &sc) {   return sc.getCount( ); }

From the SelectionCombos.H File

#if !defined(_(——)SELECTIONCOMBOS_H_(——)) #define _(——)SELECTIONCOMBOS_H_(——) #pragma warning(push) #include <yvals.h> #pragma warning(disable : 4512) #include <map> #pragma warning(pop) #pragma warning(disable : 4786) #define UNDEFINED −1 typedef std::map<Dm_Node*, Dm_Node*> MapNode; typedef std::map<int, NodeArray> MapCache; enum UsageType {UTDontCare, UTNotUsed, UTSelected}; enum SourceType {STNone=0, STInclude=1, STExclude=2, STBoth=3}; /**************************************************************************************** \   Class: SelecionCombos   Description:    This routine will return a tree that contains the advice for the input set of    selections.    Keep in mind:     The inputs can be multi-select.     We need to look through pending attributes.   Issues:    What if the attributes of the input set are not all related. This shouldn't    be a problem at all. Relationships should not be an issue in this algorithm.    Do we need to create a smaller exclude tree also? Yes, or we can HAND out    all of the excluded items.    We need to get the group information down to this class. \**************************************************************************************** / class SelectionCombos {   bool m_bHasExcludedEnums;   int m_nNCCount, m_nNumGroups, m_nNumBookmarks;   Dm_Manager *m_ddI, *m_ddX;   Dm_Node *m_pZddI, *m_pCurI, *m_pZddX, *m_pCurX;   GroupItem *m_pGroupInfo;   IntArray m_aSelections, m_aInputGroups, m_aOutputGroups, m_aEnumUsage, m_aEnumSource, m_aGroupSource, m_aEnum2Group;   MapNode m_GenCache;   NodeArray m_aNodeCache;   MapCache m_Bookmarks; private:   bool isComboExcluded(IntArray &aCombo);   void buildEnumSource(Dm_Node *pCur, int nCurSource);   void buildEnumUsage( );   void clear( );   Dm_Node *removeIndexes(Dm_Manager *dd, Dm_Node *pZdd);   Dm_Node *addAlwaysPaths(Dm_Node *pInZdd);   Dm_Node *removeExcludedPaths(Dm_Node *pI, Dm_Node *pX); public:   /********************************************************************************** **\    Proc: SelectionCombos − Constructor   \********************************************************************************** **/   SelectionCombos( )   {    m_nNumBookmarks = UNDEFINED;   }   /************************************************************************************ **\    Proc: ˜SelectionCombos − Destructor   \************************************************************************************ **/   virtual ˜SelectionCombos( )   {    clear( );   }   void generateCombos( );   int getCount( );   bool getFirstCombo(IntArray &aCombo);   bool getNextCombo(IntArray &aCombo);   void setGroupInfo(int nNumGroups, GroupItem *pGroupInfo);   void setIncludePac(Dm_Manager *ddI, Dm_Node * pZddI);   void setExcludePac(Dm_Manager *ddX, Dm_Node * pZddX);   void setInputs(IntArray &aSelections, IntArray &aInputGroups, IntArray &aOutputGroups);   int makeBookmark( );   void gotoBookmark(int nBookmark, IntArray &aCombo); }; #endif /* _(——)SELECTIONCOMBOS_H_(——) */

From the SelectionCombos.CPP File

/************************************************************************************\   Proc: makeBookmark \************************************************************************************/ int SelectionCombos::makeBookmark( ) {   m_nNumBookmarks++;   m_Bookmarks[m_nNumBookmarks] = m_aNodeCache;   return m_nNumBookmarks; } /************************************************************************************\   Proc: gotoBookmark   Issues:    The bookmarks are not guaranteed to be in sequential order. Someone could    make 2 bookmarks, then go back to the first bookmark. If they then went    ahead just a bit and created a new bookmark, this bookmark would not be in    sequential order. This may not be a big deal. \************************************************************************************/ void SelectionCombos::gotoBookmark(int nBookmark, IntArray &aCombo) {   if ((nBookmark != UNDEFINED) && (nBookmark <= m_nNumBookmarks))   {    m_aNodeCache = m_Bookmarks[nBookmark];    aCombo.clear( );    // Get the combo from the cache.    for (int ix=0; ix<m_aNodeCache.getSize( ); ix++)     aCombo[m_aNodeCache[ix]->index] = 1;   } } /************************************************************************************\   Proc: generateCombos   Description:    As we recurse . . .    If we hit a node that is selected,     we can go down the “then” leg and can keep this node.    If we hit a node that is not selected, but is in a selected group,     we remove this node and go down the “else” leg only.    If the node is in the output group,     we keep them and go down both legs.    All other nodes,     we remove them and go down both legs.    Arrays used:     EnumUsage, InputGroups, OutputGroups, Selections.   Issues:    This will create the tree we need, but the problem is traversing this tree    will cause the data to appear to be unordered. Should we serialize the    tree to another data structure that could correctly handle the ordering    issue.     The solution for this is to reorder the tree in memory. But, reordering     is slow and expensive.    Done - We may need to add nodes for indexes that are “always”. I can see a    situation where the exclude tells us to remove indexes from groups that    aren't even in the include tree. \************************************************************************************/ void SelectionCombos::generateCombos( ) {   int  ix;   buildEnumUsage( );   m_GenCache.clear( );   //--------------------------------------------------------------------------   // Remove indexes from the include.   m_pCurI = removeIndexes(m_ddI, m_pZddI);   m_pCurI = addAlwaysPaths(m_pCurI);   // Remove indexes from the exclude.   m_pCurX = removeIndexes(m_ddX, m_pZddX);   //--------------------------------------------------------------------------   // If none of the input or output groups are in the exclude tree, we can   // skip all of the exclude processing.   m_bHasExcludedEnums = false;   for (ix=0; ix<m_aInputGroups.getSize( ); ix++)    if (m_aGroupSource[m_aInputGroups[ix]] > STInclude)     m_bHasExcludedEnums = true;   for (ix=0; ix<m_aOutputGroups.getSize( ); ix++)    if (m_aGroupSource[m_aOutputGroups[ix]] > STInclude)     m_bHasExcludedEnums = true; } /************************************************************************************\   Proc: getCount   Description:    Given a tree, this routine will return the total number of combos.    We must have a cache to stop the exponential running of this algorithm.   Issues:    Done - Exclude processing will cause paths to disappear. We want to take    this into account as we count the combos. The exclude tree has a different    ordering than the include tree. This makes the process harder.    Done - Can we just subtract the number of paths from the exclude. This    may give us a quick estimate of the total number of paths. Since we added    the always paths into the include we may get a decent estimate.    We may be counting too many paths from the exclude. It seems that we should    remove all paths from the exclude that don't have any members of the input    or output groups. \************************************************************************************/ int SelectionCombos::getCount( ) {   ClearNodeCache(m_pCurI, −1);   ClearNodeCache(m_pCurX, −1);   return CountPathsToOne(m_ddI, m_pCurI) − CountPathsToOne(m_ddX, m_pCurX); } /************************************************************************************\   Proc: getFirstCombo   Description:    Return the first combo from the tree.    We cache the nodes as well. That way we can get to the next combo much    quicker. This should be a fixed length stack. The length would be the    same as the number of groups. \************************************************************************************/ bool SelectionCombos::getFirstCombo (IntArray &aCombo) {   bool bFoundNewCombo;   Dm_Node *pNode = m_pCurI;   //--------------------------------------------------------------------------   // Add the rest of the “then” chain to the combo   bFoundNewCombo = false;   m_nNCCount = 0;   m_aNodeCache.setSize(m_nNumGroups);   aCombo.setSize(m_ddI->sizeZ);   aCombo.clear( );   while ( !Dm_IsConstant(pNode))   {    aCombo[m_ddI->invpermZ[pNode->index]] = 1;    m_aNodeCache[m_nNCCount++] = pNode;    pNode = Dm_T(pNode);    bFoundNewCombo = true;   }   //--------------------------------------------------------------------------   // Get the next combo if the current one is excluded.   if (m_bHasExcludedEnums)    while (bFoundNewCombo && isComboExcluded(aCombo))     bFoundNewCombo = getNextCombo(aCombo);   return  bFoundNewCombo; } /************************************************************************************\   Proc: getNextCombo   Description:    Given a tree and the current combo, this routine will return the next combo.    This routine will also use a cache to speed up the building of combos.     Arrays used:      GroupValue - The enum value for each group.      DepthValue - The depth at which the value was found.      ChangedValue - Whether this value was changed in this traversal or not.   Issues:    Done - Do we need to count nodes on the “else” paths of nodes that we have    found? If a member of every group is on every path to one, then we wouldn't    have to. So far this seems to be the case.    Done - Do the exclude. The exclude could happen during the generation    phase. If the exclude is not done then, the exclude may cause combos to    disappear. We should move to the next combo in this case.    Is it possible (or necessary) to jump ahead X number of combos?    How do we get “chunks” of combos? So far the routine is sequential forward    only. Is this a problem? We could cache several prior combos and jump    back (maybe).    So far, the combos will not be sorted by group. They will be sorted by    enum order, which isn't the same as group order. If the tree were reordered    to match a certain group ordering, this would be fixed. We can't just use    all permutations of the output enumerations. Some of the permutations    wouldn't be valid combinations.     Example of sort from test tree:      0, 8, -->0, 9, -->0, 11, -->3, 8, -->3, 9, -->3, 11, -->      1, 9, -->2, 9, -->4, 9, -->1, 11, -->4, 11, . . .     Solution: Order the include tree into index order. The problem is that      reordering is time costly and would slow down other operations on      the tree. \************************************************************************************/ bool SelectionCombos::getNextCombo(IntArray &aCombo) {   int ix;   bool bFoundNewCombo;   Dm_Node  *pNode;   //--------------------------------------------------------------------------   // Start at the last cached node.   ix = m_nNCCount;   do   {    ix−−;    bFoundNewCombo = false;    //----------------------------------------------------------------------    // Remove this node from the current combo.    pNode = m_aNodeCache[ix];    aCombo[m_ddI->invpermZ[pNode->index]] = 0;    pNode = Dm_E(pNode);    if (!Dm_IsConstant(pNode))    {     // Add the rest of the “then” chain to the combo.     while (!Dm_IsConstant(pNode))     {      aCombo[m_ddI->invpermZ[pNode->index]] = 1;      m_aNodeCache[ix++] = pNode;      pNode = Dm_T(pNode);     }     bFoundNewCombo = true;    }   } while (!bFoundNewCombo && (ix>0));   // -------------------------------------------------------------------------   // Get the next combo if the current one is excluded.   if (m_bHasExcludedEnums)    while (bFoundNewCombo && isComboExcluded(aCombo))     bFoundNewCombo = getNextCombo(aCombo);   return bFoundNewCombo; } /************************************************************************************\   Proc: setGroupInfo \************************************************************************************/ void SelectionCombos::setGroupInfo(int nNumGroups, GroupItem *pGroupInfo) {   m_nNumGroups = nNumGroups;   m_pGroupInfo = pGroupInfo; } /************************************************************************************\   Proc: setIncludePac \**********************************************************************************/ void SelectionCombos::setIncludePac(Dm_Manager *ddI, Dm_Node * pZddI) {   m_ddI = ddI;   m_pZddI = pZddI; } /************************************************************************************\   Proc: setExcludePac \************************************************************************************/ void SelectionCombos::setExcludePac(Dm_Manager *ddX, Dm_Node * pZddX) {   m_ddX = ddX;   m_pZddX = pZddX; } /************************************************************************************\   Proc: SetInputs \************************************************************************************/ void SelectionCombos::setInputs(IntArray &aSelections, IntArray &aInputGroups,           IntArray &aOutputGroups) {   m_aSelections = aSelections;   m_aInputGroups = aInputGroups;   m_aOutputGroups = aOutputGroups; } /************************************************************************************\   Proc: isComboExcluded   Description:    Check if the current combo is excluded. If there are any paths to one that    contain any part of the current combo, then the path is excluded. \************************************************************************************/ bool SelectionCombos::isComboExcluded(IntArray &aCombo) {   bool  bRet = false;   NodeStack stack;   Dm_Node     *pCur = m_pCurX;   //--------------------------------------------------------------------------   // Clear out the node cache.   ClearNodeCache(pCur, −1);   do   {    //----------------------------------------------------------------------    // If we hit a constant or a cached node, we will pop off the stack.    if (Dm_IsConstant(pCur) ∥ (pCur->cCache == 1))    {     if (stack.getSize( ) > 0)      pCur = stack.pop( );    }    //----------------------------------------------------------------------    // Check if this index is in the current combo. This will guide us    // through the exclude. If the next “then” node is a constant−1, then    // we have a path that can be excluded, so return true immediately.    if (!Dm_IsConstant(pCur))    {     if (aCombo[pCur->index] == 1)     {      pCur->cCache = 1;      stack.push(Dm_E(pCur));      pCur = Dm_T(pCur);      if (pCur == Dm_ONE(m_ddI))      {       bRet = true;       break;      }     } else {      pCur = Dm_E(pCur);     }    }   } while (stack.getSize( ) > 0);   return bRet; } /************************************************************************************\   Proc: buildEnumSource   Description:    Build the arrays that tell where enumerations (and their groups), come    from. Either from the include, exclude, both or not used. \************************************************************************************/ void SelectionCombos::buildEnumSource(Dm_Node *pCur, int nCurSource) {   NodeStack stack;   //--------------------------------------------------------------------------   // Clear out the node cache.   ClearNodeCache(pCur, −1);   do   {    if ((pCur->cCache == nCurSource) ∥ Dm_IsConstant(pCur))    {     if (stack.getSize( ) > 0)      pCur = stack.pop( );     else      pCur = NULL;    } else {     m_aEnumSource[pCur->index] += nCurSource;     m_aGroupSource[m_aEnum2Group[pCur->index]] += nCurSource;     pCur->cCache = nCurSource;     stack.push(Dm_E(pCur));     pCur = Dm_T(pCur);    }   } while ((stack.getSize( ) > 0) && (pCur != NULL)); } /************************************************************************************\   Proc: buildEnumUsage( )   Description    This array is only used during the generation of combos phase.    How a particular enum is used for input.     UTSelected means selected.     UTNotUsed means not used but in a selected grouop, therefore ignore it.     UTDontCare means don't care. \************************************************************************************/ void SelectionCombos::buildEnumUsage( ) {   int  ig, ix, iy;   //--------------------------------------------------------------------------   // Build the enum usage array   m_aEnumUsage.setSize(m_ddI->sizeZ);   m_aEnumUsage.clear(UTDontCare);   for (ix=0; ix<m_aInputGroups.getSize( ); ix++)   {    ig = m_aInputGroups[ix];    for (iy=m_pGroupInfo[ig].nGroupStart; iy<=m_pGroupInfo[ig].nGroupEnd; iy++)     m_aEnumUsage[iy] = UTNotUsed;   }   for (ix=0; ix<m_aSelections.getSize( ); ix++)    m_aEnumUsage[m_aSelections[ix]] = UTSelected;   //--------------------------------------------------------------------------   // Build the enum to group conversion array.   m_aEnum2Group.setSize(m_ddI->sizeZ);   for (ix=0; ix<m_nNumGroups; ix++)    for (iy=m_pGroupInfo[ix].nGroupStart; iy<=m_pGroupInfo[ix].nGroupEnd; iy++)     m_aEnum2Group[iy] = ix;   //--------------------------------------------------------------------------   // Scan the include and exclude trees to determine which enums are used where.   m_aEnumSource.setSize(m_ddI->sizeZ);   m_aGroupSource.setSize(m_nNumGroups);   buildEnumSource(m_pZddI, STInclude);   buildEnumSource(m_pZddX, STExclude); } /************************************************************************************\   Proc: clear \************************************************************************************/ void SelectionCombos::clear( ) {   m_aSelections.clear( );   m_aInputGroups.clear( );   m_aOutputGroups.clear( );   m_aEnumUsage.clear( );   m_aEnumSource.clear( );   m_aGroupSource.clear( );   m_aEnum2Group.clear( );   m_aNodeCache.clear( );   m_GenCache.clear( );   m_Bookmarks.clear( ); } /************************************************************************************\   Proc: removeIndexes   Description:    This is the recursive routine that builds the include based upon the enums    that are selected.   Issues:    Todo - Need to add a cache to this routine. \************************************************************************************/ Dm_Node *SelectionCombos::removeIndexes(Dm_Manager *dd, Dm_Node *pZdd) {    Dm_Node   *t, *e, *r;   //--------------------------------------------------------------------------   // Get it out of the cache if possible.   r = m_GenCache[pZdd];   if (r != NULL)    return r;   //--------------------------------------------------------------------------   // Handle constants   if (Dm_IsConstant(pZdd))    return pZdd;   //--------------------------------------------------------------------------   // Handle each node.   if (m_aEnumUsage[pZdd->index] != UTNotUsed)    t = removeIndexes(dd, Dm_T(pZdd));   else    t = NULL;   //--------------------------------------------------------------------------   // Always do the “else” leg.   e = removeIndexes(dd, Dm_E(pZdd));   r = (t == NULL) ? e : Dz_ZddGetNode(dd, pZdd->index, t, e);   m_GenCache[pZdd] = r;   return r; } /************************************************************************************\   Proc: addAlwaysPaths   Description:    We need to add nodes to the include tree that are always, because they are    only excluded from the exclude tree.    For example: If the exclude has group 2 and 3 (which arent in the include),    and the exclude says that 21 × 31 and 23 × 31. That would make all of enuins    in group 2 and 3 always. only 2 combinations of from all of these group are    excluded. All other combinations are implicitly included. We would need to    add an XOR for groups 2 and 3 to the include, so that they could be excluded.    So . . . any group that is ONLY in the exclude, needs an XOR added to the    include.   Issues:    Done - Unordered version - We could also build the tree by doing a union on    a group by group basis. Each group would be built seperately. This wouldn't    be too hard. Just have to make sure to hit each group member in reverse    order from its position in the tree. We could do a backwards scan through    InvPermZ and enum2Group. When we hit a member of the target group we would    add it to the tree immediately. \************************************************************************************/ Dm_Node *SelectionCombos::addAlwaysPaths(Dm_Node *pInZdd) {   int   ix, iy;   Dm_Node    *pCur, *pZdd;   //--------------------------------------------------------------------------   // Add all of the enums for groups that are only in the exclude.   pZdd = pInZdd;   for (ix=0; ix<m_nNumGroups; ix++)   {    if (m_aGroupSource[ix] == STExclude)    {     // We have to look at all enums in reverse order     pCur = Dm_ONE(m_ddI);     for (iy=m_ddI->sizeZ−1; iy>=0; −−iy)     {      int nTerm = m_ddI->permZ[iy];      if (m_aEnum2Group[nTerm] == m_aGroupSource[ix])       pCur = Dz_ZddGetNode(m_ddI, nTerm, pCur, Dm_ONE(m_ddI));     }     //--------------------------------------------------------------------------     // Union the enums for this group into the total zdd.     pZdd = Dz_zddUnion(m_ddI, pZdd, pCur);    }   }   return pZdd; } 

1. A computer-implemented method of providing a list of product choices from products having specifications whose compatibility is characterized by a ZDD rule model including one or more Include or Exclude rules, said list of product choices being provided in response to user-selected attributes and/or enumerations, said method comprising: selecting attributes and enumerations thereof from a list of attributes and enumerations of said products, creating a ZDD sub-tree by scanning the Include rules and keeping paths having user-selected enumerations set, determining paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, checking the potentially valid combinations against the Exclude rules to determine valid combinations and excluding said combinations that are excluded under the Exclude ZDD, and providing the valid combinations to a user as an indication of valid product choice.
 2. The method of claim 1, wherein said providing step includes displaying valid product choices on a display monitor.
 3. The method of claim 2, wherein said scanning includes examining nodes of the Include ZDD against an Index value of selected enumerations to create a node in the ZDD sub-tree.
 4. The method of claim 3, wherein said scanning further includes examining nodes of the ZDD sub-tree against an Index value of selected enumerations to recursively create a node in the ZDD sub-tree.
 5. The computer-implemented method of claim 4, wherein potentially valid combinations of the determining step comprise nodes of paths terminating at a “one” node of the ZDD sub-tree.
 6. An apparatus to provide a user with a list of product choices from products whose compatibility is characterized by a ZDD rule model having one or more Include and Exclude rules, said list of product choices being provided in response to user-selected attributes and/or enumerations, said apparatus comprising: an input device to enable selection of attributes and enumerations thereof from a list of attributes and enumerations of said products; a processor including routines to effect creation of a ZDD sub-tree by recursively scanning the Include ZDD and keeping paths having user-selected enumerations set, to determine paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, and to check the potentially valid combinations against the Exclude ZDD to find valid combinations, and an output device that outputs the valid combinations as an indication of valid product choice.
 7. The apparatus of claim 6, wherein said input device comprises one of a keyboard and a pointing device, and said output device comprising one of display monitor and a printer.
 8. The apparatus of claim 7, wherein said processor additionally effects examination of nodes of the Include ZDD against an Index value of selected enumerations to create a node in the ZDD sub-tree.
 9. The apparatus of claim 8, wherein said processor effects examination of nodes of the ZDD sub-tree against an Index value of selected enumerations to recursively create a node in the ZDD sub-tree.
 10. The apparatus of claim 9, wherein said processor identifies valid combinations the nodes of paths in the ZDD sub-tree that terminate at a “one” node of the ZDD sub-tree.
 11. A computer-readable medium to effect operation of a computer to provide a list of product choices having specifications whose compatibility is characterized by a ZDD rule model including one or more Include or Exclude rules, said list of product choices being provided in response to input specifications in the form of user-selected attributes and/or enumerations, said computer-readable medium including program instructions to effect selection of attributes and enumerations thereof from a universe of attributes and enumerations of said products, creation of a ZDD sub-tree by recursively scanning the Include rules and keeping paths having user-selected enumerations set, determination of paths through the ZDD sub-tree terminating at a “one” node to produce potentially valid combinations, checking potentially valid combinations against the Exclude rules to determine valid combinations and excluding said combinations that are excluded under the Exclude rules, and provision of valid combinations to a user as an indication of valid product choice.
 12. The computer-readable medium of claim 11 further including program instructions to effect a display of valid product choices on a display monitor.
 13. The computer-readable medium of claim 12 further including program instructions to effect an examination of nodes of the Include rules against an Index value of selected enumerations to create a node in the ZDD sub-tree.
 14. The computer-readable medium of claim 13 further including program instructions to effect examination of nodes of the ZDD sub-tree against an Index value of selected enumerations to recursively create a node in the ZDD sub-tree.
 15. The computer-readable medium of claim 14 further including program instructions to determine nodes of paths terminating at a “one” node of the ZDD sub-tree as valid combinations. 